Business Analyst Community & Resources | Modern Analyst

Business Analysis in the Age of AI

Pulkit Singhal — Fri, 01 May 2026 19:24:00 GMT

Business analysis work has become faster and more efficient over the past few years. Requirements are documented more quickly, discussions are summarized sooner, and solution options are produced earlier in the delivery cycle than ever before. Yet many Agile and product teams are discovering an unexpected truth: as delivery accelerates, the importance of human judgment increases rather than diminishes.

The central question facing business analysts today is no longer whether tools and automation belong in analysis work, but where judgment must take precedence. That distinction matters because the most serious failures in delivery rarely come from obvious mistakes. They emerge from reasonable decisions that appear correct at the time and gradually move teams off course.

Where Acceleration Helps and Where It Falls Short

Modern analysis practices are excellent at speeding up work that is inherently mechanical:

Converting discussions into draft requirements
Identifying patterns across large volumes of data
Refining user story language
Summarizing customer or stakeholder feedback

When used well, this removes low‑value effort from the analyst’s workload. When relied upon uncritically, it creates the illusion of progress.

The challenge is not poor quality output. The real risk lies in outputs that are clear, structured, and confident enough to pass surface review, while subtly reinforcing incorrect assumptions. This is where judgment becomes decisive.

Judgment Gap #1: Determining Whether a Requirement Is Worth Building

Clear and complete requirements do not guarantee meaningful outcomes.

In day‑to‑day delivery, analysts encounter familiar patterns:

A requirement addresses a visible symptom rather than the underlying problem
Stakeholders agree on wording but diverge on expected results
A feature meets acceptance criteria yet produces no behavioral change

Experienced analysts pause to ask questions that artifacts alone cannot answer:

What decision or behavior is supposed to change as a result of this work?
If this is delivered perfectly and nothing improves, what are we missing?

Strong analysis is not just about expressing requirements well, but about challenging their intent.

Judgment Gap #2: Interpreting Context That Never Appears in Documentation

Business environments contain layers of context that rarely make it into requirements or datasets:

Organizational dynamics and power structures
Regulatory concerns driving risk‑averse behavior
Legacy failures that shape stakeholder trust
Competing incentives across teams

Analysts recognize these signals not because they are documented, but because they have seen the downstream effects:

Solutions that are functionally correct but poorly adopted
Processes that are bypassed in practice
Reports and dashboards that exist but are ignored

Judgment here is not guesswork. It is pattern recognition developed through exposure to real consequences.

Judgment Gap #3: Recognizing When Clarity Creates False Confidence

Early clarity is often welcomed as momentum. Detailed backlogs, well‑defined flows, and polished models can make teams feel aligned and confident.

Seasoned analysts remain cautious.

They ask whether clarity is reducing uncertainty—or simply hiding it:

Are assumptions being locked in too early?
What would invalidate this design once it is tested?
Are open questions being resolved, or quietly deferred?

Sometimes the most responsible decision is to leave things deliberately unresolved, even when tools and processes encourage premature finalization.

What This Means for Business Analysts

As delivery mechanics become faster, the value of business analysis shifts away from producing artifacts and toward exercising judgment:

Framing the right problems
Interpreting conflicting signals
Evaluating consequences under uncertainty
Challenging assumptions before they harden

These capabilities are not procedural skills. They are developed through experience, reflection, and exposure to real outcomes especially failure.

Closing Thoughts

Modern tools and practices have made business analysis more efficient, but efficiency does not replace responsibility. The most effective analysts are not those who produce the most artifacts in the shortest time. They are the ones who know when clarity is helpful, when it is premature, and when the best contribution is to pause and ask a different question altogether.

That work remains deeply human and central to successful delivery.

Reinventing the Annual Member Survey: A Business Analyst’s Role in Delivering Actionable Insights

Pulkit Singhal — Sun, 25 Jan 2026 02:38:00 GMT

In a competitive and rapidly evolving financial landscape, understanding member needs is vital to maintaining strong relationships and delivering meaningful value. Yet for many institutions, especially those with legacy processes, collecting structured member feedback can be surprisingly underdeveloped. This was the case at the Federal Home Loan Bank of Chicago (FHLBank Chicago), where — despite its extensive engagement with member institutions — the Bank had never before conducted a structured, enterprise-wide Annual Member Survey.

Recognizing the need for a formalized feedback mechanism, the Bank launched an initiative to design and implement its first-ever Annual Member Survey, leveraging Salesforce as the foundational platform. As the Lead Business Analyst, I was responsible for envisioning, architecting, and orchestrating this new capability from the ground up.

This initiative ultimately became a defining example of how strategic business analysis can create net-new organizational capability, not just improve existing processes.

The Challenge: Creating a Strategic Feedback Framework from Scratch

Unlike most process-automation projects, this effort did not begin with an existing workflow to analyze or improve. Instead, the Bank faced a unique challenge:

No prior survey process existed
No historical data or response structures were available to benchmark against
No distribution, tracking, or reporting mechanisms had been established
No governance model existed for how results should be consumed
Stakeholders possessed varying assumptions about what the new survey should accomplish

This meant the project required not only systems expertise but also conceptual design, stakeholder alignment, and strategic framing.

My Role as Lead BA: Designing a New Enterprise Capability

The absence of an existing process meant that Business Analysis would shape the entire direction of the initiative. My responsibilities included defining the business problem, creating the process architecture, establishing data structures, and ensuring Salesforce could support a sustainable and scalable survey model.

1. Establishing the Vision and Framing the Purpose

Through interviews and collaborative workshops with Member Strategy, Sales, Analytics, and Leadership teams, I led discussions to answer foundational questions:

What insights should the Bank gather annually?
How should “member satisfaction” be defined in measurable terms?
What KPIs would create genuine value for leadership?
How should results be tied back to member institutions in Salesforce?

This work produced the Bank’s first Survey Vision and Strategy Framework, guiding all subsequent design decisions.

2. Building the End‑to‑End Survey Workflow in Salesforce

Because no prior workflow existed, I architected a brand‑new process designed around clarity, automation, and scalability:

Designed the survey creation and distribution model
Built logic for survey-to-member linking
Defined the response-collection data structure
Modeled the end‑to‑end visibility lifecycle, including assignment, participation, reminders, and results
Ensured dashboards would give leadership real-time insights

The process not only captured survey responses but also embedded insights directly into the Bank’s member management ecosystem.

3. Translating Ambiguity Into Clear, Actionable Requirements

Given the lack of precedent, requirements had to be derived through deep analysis rather than comparison. I authored:

Detailed user stories
Acceptance criteria
Process maps
Data models
Reporting definitions

This documentation became the foundational blueprint for developers, testers, and end-users — eliminating ambiguity and creating shared understanding.

4. Leading UAT and Validating a New Capability

Because the Bank had never conducted a survey like this, UAT required additional rigor:

I designed test scripts covering every stage of the survey lifecycle
Trained business stakeholders on how to test a process that was entirely new
Triaged defects and clarified user expectations
Ensured the system was intuitive and future-proofed

Through this, the Bank gained confidence not just in the technology, but in the process itself.

5. Supporting Rollout, Adoption, and Governance

Beyond system delivery, I worked closely with:

Member Strategy teams to formalize interpretation of results
Analytics teams to align on scoring and reporting methodologies
Change management teams to ensure smooth onboarding
Salesforce admins to embed long‑term maintainability

This ensured the survey became an annual, repeatable, institution-wide capability—not a one‑off project.

Conclusion: This project shows that Business Analysts are not just process improvers—they are capability creators.By clarifying needs, defining strategy, architecting processes, aligning teams, and ensuring quality, the BA function enabled FHLBank Chicago to establish a powerful new insight mechanism that will shape strategy for years to come.

The Annual Member Survey is now more than a project deliverable.
It is a permanent intelligence asset for the Bank — built on a foundation of Business Analysis leadership.

The End is Near!

TheBori — Wed, 27 Jul 2022 17:02:00 GMT

I’ve heard “The End is Near!” for Business Analysts for almost 20 years. Waterfall project management, with its need for formal requirements, is dead…a dinosaur…so 1990’s. To be honest, that’s mostly true. With the publishing of the Agile Manifesto in 2001 there was no need for a 2-inch-thick formal requirements document. I’ve written them, and to be honest, I don’t miss them. Agile espoused iterative, rapid development and quick delivery of functionality, whether it be big or small, allowing a project team to…well…be agile. Direction, goals, deliverables and requirements could be adjusted, redirected or scrapped altogether every few weeks. “Wait a minute Mike, I just heard you say the ‘R’ word, as in... ‘Requirements’”. Yes, I did…and it wasn’t a mistake. With very few exceptions, every project needs requirements. You need to know what the project is supposed to deliver, why there is a team and a budget…and why the project has some catchy name (typically in the form of a questionable acronym).

Here how it’s supposed to work (feel free to skip ahead if this isn’t your first Agile Rodeo): In a fully adopted Agile project (I know “Agile” comes in many flavors. Scrum, Kanban, Lean, SAFe…I’m talking about Scrum. Don’t get all worked up about it.), the customer (aka the “business”) is a part of the team. They speak directly to the developers and describe what they want the solution to do. The business and the developers go back and forth discussing, defining and refining, until the developer has a pretty good idea what to build. The developer runs off and writes code, tests it and demonstrates it to the business at the end of the Sprint. The team (including the customer) review what was built and demonstrated, and accept or redirect the next round of work…lather, rinse, repeat.

I have spent a good bit of my career keeping the business away from the developers. Developers are great people. They have fantastic skills, deep understanding of their trade and they really, really want to help. In fact a developer will deliver exactly what the customer says they want….GAAAA! I don’t want to speak ill of the customer, but what they want and what they need are not always the same thing. As a BA it’s my job to understand what the business does, needs and should or shouldn’t have…and to translate that into something the developer understands. There is often a lot of pushback and justification…a lot of wailing and gnashing of teeth.

Enter the Agile Product Owner. While a BA, in the classic sense, is not on the list of Agile Team Members, there is still a need to bridge the gap between customers and overly-helpful developers. An Agile Product Owner has an understanding of what the final deliverable product should be (remember, it’s not the job of the BA, customer or Product Owner to define HOW functionality should be delivered, just WHAT the deliverables are) and prioritizes the work accordingly.
So, no, we don’t need a BA on our Agile Team. Instead of a BA going out to define current state and understand the future state business needs, writing those need in a form the developers understand and prioritizes them, we just need a PO who understands what the business needs, can write those needs in a form the developers understand and prioritizes them…hmmmm. BA? PO? I’ll have to ask HR which one pays better.

Mike is a Principal Consultant and the Business Strategy Technology Lead at Moser Consulting. With a degree in Ceramic Engineering from Rutgers University, Mike’s career has been focused almost exclusively on process design and improvement. He started with process and materials design for aerospace coatings in the late ‘80s, and made the switch to IT after saving the company from the sure destruction of Y2K. Over his 30+ year career Mike has had the pleasure of digging into processes in regulated pharma, manufacturing, field service, government, insurance, airlines, marketing, and utilities, among others, and would love to experience more. Drop him a line on LinkedIn (www.linkedin.com/in/Michael-Boris-MoserIT) or at Michael.Boris@MoserIT.com

Who is a Business Analyst

Millicent Umeh — Sat, 23 Jul 2022 10:41:00 GMT

You’ve probably been hearing about Business Analysis or you’ve never heard of it before and you want to understand what it truly means. This is the right article for you if you’re under this category!

Before we go further, we need to know what the term ‘Business Analysis’ means. According to the Business Analysis Body of Knowledge (BABOK), ‘Business Analysis is the act of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders.’ So we can easily say that Business Analysts are enablers of change. Business Analysts do not fear change, rather they embrace it.

So who is a Business Analyst?

A Business Analyst performs any of the Business tasks described in the BABOK, no matter their job title or organizational role.

A Business Analyst identifies the actual need or problem of an organization, translates those needs into functional and non-functional requirements, and recommends solutions to the stakeholders. Business Analysts access the organization or company’s current state, to define the future state and identify the steps required to move from the current state to the future state. The role of a Business Analyst requires a lot of communication (usually a back and forth process) and collaboration. This is because they are the bridge between the stakeholders or the business world and the Technical team. They facilitate stakeholder collaboration, understand problems and goals, analyze needs and solutions, devise the right strategies, and drive change.

Ever heard about the story of a group of blind men and the elephant? It is a story of a group of blind men who have never come across an elephant before and who learn and imagine what the elephant is like by touching it. Each blind man feels a different part of the elephant’s body, but only one part, such as the side or the tusk. They then describe the elephant based on their limited experience and their descriptions of the elephant are different from each other.

Let us align that story to a business world without someone who performs the role of a Business Analyst. Sometimes, we don’t know what we truly want until we get clarification. Even most ideas don’t come out fully formed.

The Business Analyst can be likened to be the eye through which the customers and stakeholders see. They are customers centric and without them, projects could pan out like the group of blind men and the elephant or the image below.

Business Analysts are involved in all phases of the Software Development Life Cycle. They do not just stop at gathering requirements and recommending them, they ensure that all the requirements are met from initiation to closure of the project, and even after the project, they are still involved. Business Analysts discover, develop, analyze and synthesize a lot of information and they focus on delivering value to not just the stakeholders, but their customers as well.

Truth is, the role of a Business Analyst differs from organization to organization and they go by various titles sometimes.

Some of these titles are; Systems Analyst, Product Owner, Requirements Engineer, Business Operational Analyst, Information Architect, Agile Business Analyst, Business Architect, Data Analyst, Product Manager, Process Analyst, Management Consultant, IT Business Analyst, etc.

Top 10 Mistakes in Requirements Elicitation

Trividh Patel, CBAP — Tue, 27 Apr 2021 05:47:00 GMT

Elicitation involves bringing out or drawing out information. Elicitation is a key task in business analysis as without proper elicitation the requirements for the solution to the business needs cannot be identified.

1. Not understanding underlying business need

Organization’s business environment keeps changing with respect to Customers, Marketplace, Technology and Marketing function. It is these changes in business environment that leads to identification of business needs at the strategic level in terms of problem or opportunity faced by the organization.

Defining business needs is the most important step in business analysis. Without understanding and defining underlying business needs, it would not be possible to identify all affected stakeholders and elicit appropriate requirements.

2. Not identifying all affected stakeholders

It is important to identify all the stakeholders affected by the given business need. If any stakeholder is identified late (or worst not at all!) may lead to incomplete set of requirements and could require a revision to requirements increasing project cost and time.

3. Treating elicitation as a phase

I have found many Business Analysts consider elicitation as a phase after planning (and before requirements analysis). But this is not true. If you think little more deeply, information gets elicited whenever we interact with stakeholders such as sponsor, domain subject matter experts (SMEs), implementation SMEs, users etc.

Elicitation is performed to understand the current state and elicit business requirements. Business requirements are used when eliciting stakeholder, solution and transition requirements. During requirements analysis, we may identify gaps which would require further elicitation. Information is also elicited from the stakeholders about solution performance after implementation of a new solution.

So elicitation is performed on an ongoing basis as long as business analysis work is performed.

4. Not asking probing questions to elicit requirements

Many novice Business Analysts assume stakeholders can proactively provide all the detailed information required for the business analysis work. Such a passive approach can be called requirement gathering but not an elicitation. Such an approach can only lead to identification of shallow requirements.

It is the job of the Business Analyst to extract or draw out the detailed requirements from the minds of the stakeholders. Business Analyst need to ask probing questions to elicit detailed requirements.

5. Not setting stakeholder’s expectations

In your career as a Business Analyst, at times you would find some stakeholder who would state their wants (whims and wishes!) as if they are their needs and expect them to be in the solution. You may find their expectations not only difficult but impossible. If you capture their wants as requirements it would be difficult later on to deliver to their expectations.

With your interpersonal and negotiation skills you need to communicate and set the right expectations.

6. Not using combination of complementary elicitation techniques

I have seen many Business Analysis teams often rely only on one technique such as interviews for elicitation. While interviews is the most effective elicitation technique but its effectiveness depends on the skills of the Business Analyst such as business domain knowledge and ability to ask probing questions.

So, apart from interviews, a Business Analyst should have knowledge of other commonly used fundamental requirements elicitation techniques such as Document Analysis, Observation and Prototyping. While a senior Business Analyst should have knowledge of advanced elicitation techniques such as Brainstorming, Focus Groups, Requirements Workshops and Surveys.

A Business Analyst should be able to understand the given situation and use combination of complementary elicitation techniques.

7. Not eliciting assumptions and constraints

Requirements are often stated (knowingly or unknowingly) based on certain assumptions which are believed to be true at that time. Requirements get impacted if those assumptions are later found to be false.

Constraints are limitations or restrictions (such as regulatory restrictions, budgetary restrictions, time restrictions etc) that restrict potential solutions to requirements. Identified potential solutions may change if there are any changes in the constraints.

If underlying assumptions and constraints are not captured for requirements, it would be difficult to assess impact on requirements if certain assumptions are later found to be false and/ or on potential solutions if constraints are changed.

8. No plan to elicit requirement iteratively

In order to elicit requirements, a Business Analyst contacts a stakeholder and requests their time. Many Business Analysts do not plan to elicit requirements iteratively and assume that stakeholders will provide all the information required for the business analysis work.

However, most of times, stakeholders are not aware why they are being contacted. After their initial meetings, stakeholder will have some idea what is expected out of him/ her. In the subsequent meetings, stakeholder is likely to give bit more detailed information. So, in order to elicit detailed information, Business Analyst needs to plan to elicit requirement iteratively.

9. Not confirming the elicited information

Work of elicitation is not over once Business Analyst is done talking to stakeholders. Business Analyst has to organize the elicited information and send it to the stakeholders for review. The purpose is to check if discussion has been properly documented and confirm the elicited information.

10. Not collaborating with stakeholders to have common understanding of requirements

When the elicited requirements are shared with stakeholders, there can be difference of opinions and conflicts between stakeholders. A Business Analyst has to collaborate, mediate and resolve conflict between stakeholders to reach a common understanding of requirements. Business Analyst should identify the stakeholder’s problems and help to identify solutions to satisfy those problems.

About Author - Trividh Patel, CBAP

Trividh Patel has about 20 years of experience in Business Analysis and Consulting in IT services industry.

Currently, he is working as Facilitator and Mentor - Business Analysis providing self-paced online courses in Business Analysis. Previously, he has worked for leading IT Services companies as Business Architect, Lead/ Sr. Business Analyst, and as IT Project Manager. He has executed several business analysis projects for reputed organizations from USA, UK, Europe, Middle East, Japan and India. He has good track record of leading team of Business Analysts to deliver business analysis projects.

Trividh Patel has done MBA in Systems and Bachelor of Engineering from University of Mumbai (India) and is Certified Business Analysis Professional (CBAP) by International Institute of Business Analysis (IIBA), Canada since March 2012. He is also Certified Six Sigma Black Belt.

For Consulting, Coaching or Guidance on IIBA Certification (or just to connect!), Trividh Patel can be reached on LinkedIn: http://www.linkedin.com/in/trividhpatel-cbap

Trust in conflict – The healthy way to pick a fight!

Pjbussol — Tue, 26 Jun 2018 18:15:00 GMT

TRUST IN CONFLICT - THE HEALTHY WAY TO PICK A FIGHT!

Perched on top of the Royal Liver Building in Liverpool, the city I grew up in, is a very special couple; married for over 100 years and standing 18ft tall the legendary Liver Birds, Bella and Bertie have unflinchingly protected the city and her people since 1911. Bella looks out to the River Mersey keeping an eye on Liverpool’s seafarers whilst Bertie looks inwardly towards the city watching over their families. In essence they have two very different roles but one common objective, to protect the people and prosperity of Liverpool.

This type of Janus Relationship is often used to illustrate the relationship between the Project Manager and the Business Analyst and rightly so. The two roles are very different but there is a shared objective - The successful delivery of a quality product.

It stands to reason then that meeting this objective is dependent on the Business Analyst and the Project Manager always being in agreement and always getting along then right? Wrong! Let’s be very clear, conflict is healthy - so long as it approached in a positive way. When done right conflict can enthuse, harvest trust and build rapport. However, done badly, conflict can be catastrophic. Negative conflict can kill any project and have serious and lasting impacts on the people involved. So, how do we promote healthy conflict?

TRUST AND RESPECT

Sounds like a cliché but it is imperative that the Business Analyst and the Project Manager respect each other’s professional boundaries – In the modern workplace it is very easy (and often encouraged) for these roles and responsibilities to become blurred but as mere primates we all react badly when we feel our personal space is being invaded. It is therefore natural for friction to occur if one feels that their professional territory is being annexed. Often this annexation happens when one party does not fully understand the others role or genuinely trust the others judgement or ability to deliver.

PROVE YOURSELF

So how do we develop that trust? Rather cynically, I believe that we are all inherently distrusting of ‘strangers’ and changing our initial opinion requires some effort. When establishing new working relationships, personal beliefs need be formed and developed and cemented over time. This is why trust cannot be built overnight. In my humble opinion, the most powerful way to build trust is to deliver. Take every opportunity to demonstrate your brilliance and prove that you have each other’s back but be very careful… You must be genuine, you must be consistent, you must be honest and you must be assertive – Let the storming, norming and forming commence!

COLLABORATE

In my experience the projects that run most smoothly are those were the Business Analyst and the Project Manager have an equal stake in the game. The relationship is one of a partnership were each other’s strengths and weaknesses are well understood and were opportunities to support each other are sought rather than opportunities to catch each other out. In a strong collaborative partnership both parties are in sync and present a united front – one managing the needs of the business the other the needs of the project, but always ‘on message’ and working in a truly Janus fashion.

FEEL PSYCHOLOGICALLY SAFE

A friend of mine used this phrase during a conversation recently to describe high performing workplaces – Essentially it refers to the creation of a culture where people feel relaxed being their real selves; there is no act and there are no pretences. This requires serious respect, trust and a colossal level of emotional intelligence but to crack this is to find the holy grail of project success. Admittedly you may have little control over how psychologically safe your organisation is but you can affect your immediate environment. You can ensure that all members of the team feel comfortable expressing ideas and opinions and that they are really listened to. There is no better way to encourage innovation, enthusiasm and good, healthy, positive conflict. Team members will immediately flag concerns, ask questions or seek clarification, without fear of humiliation or blame and knowing that their professional credibility and worth are not being judged.

The Business Analyst and Project Manager both benefit greatly from a psychologically safe environment but have a significant role in creating it... We must ask the right questions and deeply probe responses to ensure that we really understand our team members and our stakeholder’s point of view. We must discourage dominating behaviours and we must accept that we are all fallible and that, under the right circumstance, failure is always an option and even better if it happens fast! – How else do we learn?

IN CONCLUSION…

The role of Business Analyst is very different to that of a Project Manager however both are equally important to the success of a project. The Business Analyst will work with the business to understand their needs and define the right product whilst the Project Manager will ensure that product is delivered in a timely and efficient way; although both have the same end goal there are often competing priorities which can result in conflict. However, this is not necessarily a bad thing. When working as a professional partnership the chances of success are significantly increased especially if both parties are prepared for and welcome healthy conflict.

In order to ensure conflict is healthy, there must be a solid foundation of trust and mutual respect for each other’s roles. Every opportunity should be taken to develop this trust through consistent, high quality delivery, leading to a truly collaborative relationship. Ultimately a psychologically safe environment should be cultivated for the good of the project and all of those involved. A psychologically safe environment is the key to a highly functioning and highly performing team. But what happens when conflict is not properly managed or if relationships turn sour? Well, legend has it that if either Bella or Bertie decided to fly away, the River Mersey would burst its banks and flood the city of Liverpool. So, fair to say it wouldn’t be good news for anybody!

Disaster Recovery and the Role of the Disaster Recovery Analyst

Limor Wainstein — Wed, 14 Feb 2018 17:30:00 GMT

Disaster recovery entails processes that ensure the swift re-establishment of an enterprise’s important data, IT systems, and applications in the event of an unexpected outage caused by either a man-made or natural disaster.

The importance of disaster recovery is clear when assessing the costs to enterprises of system outages—according to a 2015 IHS study of mid- to large-size enterprises, such outages cost companies $700 billion a year across North America. The costs run so high when you consider lost revenue, loss of employee productivity, and the time taken to get systems back up and running.

It’s evident from the IHS study that recovering from system outages as quickly as possible is vital for minimizing the costs of any disaster. Below you’ll find out what a disaster recovery plan is, how disaster recovery is relevant to a business analyst, and you’ll also find out about the role of the disaster recovery analyst.

Disaster Recovery Plan

A disaster recovery plan covers the steps, policies, and tools required for an enterprise to get its technology infrastructure functioning again rapidly following a disaster. Such a plan is often developed alongside an organization’s business continuity plan.

The disaster recovery plan typically includes important recovery strategies for on-premise systems, such as using uninterruptible power supplies, backing up data to secondary locations, and even cloud-based recovery options.

AWS disaster recovery is a particularly pertinent option that emerged in recent years with the development of cloud computing, in particular those services provided by Amazon Web Services (AWS). Many enterprises now use a hybrid cloud solution that combines on-premise physical systems with cloud services such as AWS (EC2, Redshift, Aurora, etc.) to handle IT workloads more efficiently.

An enterprise can now back up its mission-critical apps and data which are handled by AWS services by using AWS disaster recovery solutions. After all, cloud computers are also at risk from man-made or natural disasters, so it makes sense to incorporate AWS disaster recovery as part of a comprehensive disaster recovery plan that covers all angles and types of system.

Who Is Responsible for Disaster Recovery?

Because disaster recovery is an important financial concern, a senior employee in the finance department should help with the development of any DR plan, such as the chief financial officer. In fact, the disaster recovery plan is of such critical importance that the central responsibility for the plan must reside on top management.

However, other employees are also responsible for helping out with drawing up an adequate plan. A committee with representatives from functional areas of the company should oversee the implementation of a DR plan.

The business analyst plays an important role in disaster recovery as the link between an enterprise’s IT and its distinct business units. More precisely, the business analyst helps to conduct a business impact analysis which analyses mission-critical business functions and quantifies the effects that a business disruption might have on those functions.

Disaster Recovery Analyst

A disaster recovery analyst is a specialist employee who helps create technical disaster recovery plans, including details on the processes for re-establishing servers, apps, databases, and operating systems in the event of a disruption (see this job description). The disaster recovery analyst tests and updates existing plans all the time to ensure they operate seamlessly and return systems to a functioning state with minimal downtime after a disaster.

The disaster recovery analyst is a relatively new role that reflects the importance of disaster recovery and the high costs that can occur when a proper plan is not in place. The traditional approach is to distribute a disaster recovery analyst’s responsibilities among several types of employee, but the argument for hiring a dedicated analyst is that he/she can better pinpoint the strategies needed for an appropriate DR plan.

Business analyst and disaster recovery analysts

A business analyst is typically seen as a professional who helps to facilitate change within an organization. As such, business analysts help to improve business processes by documenting how such processes function and helping to improve them. In this sense, a business analyst’s job could overlap with that of a disaster recovery analyst, particularly in terms of assessing the current processes and procedures used for disaster recovery.

Closing Thoughts

Rapid recovery from man-made or natural disasters is extremely important for modern enterprises. Many companies now employ hybrid cloud solutions for managing their application workloads, which broadens the range of systems that need to be considered when protecting against a system outage. Cloud-based recovery solutions such as AWS disaster recovery can help protect data and workloads stored on cloud computers.

A relatively new role has emerged in the form of a disaster recovery analyst, who specializes in helping to create disaster recovery plans and constantly refines those plans through thorough testing.

What's the Difference between Business Development, Sales Development, and Business Analysis?

Limor Wainstein — Mon, 29 Jan 2018 21:09:00 GMT

Business development broadly refers to activities that create long-term value for an organization by implementing growth opportunities for an organization, such as forming a partnership that helps sell a product in a new market.

Sales development, while closely related to business development, is a separate area that entails creating value for an organization by identifying, connecting with, and qualifying leads, moving the prospects most likely to make a purchase towards the back end of the sales cycle where they can be closed by a salesperson.

Business analysis is more focused on identifying a need for change in how businesses work and helping to facilitate such change, whether by streamlining existing processes or implementing new technologies and new ways of doing things.

The rest of the article highlights the similarities and differences in these areas, overviews the main roles involved (sales development representative, business development manager, and business analyst), and discusses some of the important skills for each role.

Differences & Similarities

Business development resembles a sales role in that it involves working to acquire new customers and clients for a business.
Business analysis is quite distinct from the other two areas because it requires a lot of data and research into how the business operates as a whole, as opposed to focusing on marketing/sales.
Business development focuses on sales from the perspective of expanding an organization’s reach into new markets, while sales development focuses on generating new sales from existing markets.
Business development can be seen as a high-level sales job, while sales development is more entry-level, and there is a path between the two areas, with business development staff often beginning in sales development roles.
Since business development impacts stakeholders, business development decisions will often include the input of the business analyst.

Sales Development

The key role within sales development is that of the sales development representative. A sales development representative is responsible for outbound prospecting. More specifically, the sales development representative receives a list of leads from marketing, who he/she is then responsible for contacting and qualifying so that closers spend more time selling to the prospects that are more likely to make a purchase.

Skills required:

Actively listening to people to best determine how to ensure you meet their needs, rather than aggressively trying to move people along the sales pipeline.
Familiarity with or ability to learn how to use CRM platforms.
Resilience: it’s important to maintain positivity when a phone call or email to a lead does not turn out as planned. SDRs must be able to quickly move on from a bad phone call or email and show the same enthusiasm for the 20th prospect contacted in a day as the 1st.

The salary for a sales development representative varies quite markedly depending on location and experience level.

Business Development

A common role in business development is the business development manager, who is tasked with helping a business grow by acquiring new customers or markets to sell to and selling new products or services to existing customers. The overarching task is to diversify a company’s clientele.

Some important skills required are:

Excellent interpersonal skills and the ability to persuade/influence people.
Strong sales and negotiation skills for developing partnerships and expanding a company’s reach into new markets.
An eye for new business opportunities through attending industry conferences and other events.
Building positive relationships.
Writing detailed reports for presentation to senior management.

Business development managers earn a median annual salary of $71,248 in the U.S.

Business Analysis

A business analyst often acts as a link between an organization’s stakeholders and its processes. The idea is that stakeholders define their needs and the business analyst then takes responsibility for translating those needs in terms of business processes and technologies that can help deliver what stakeholders want.

While some professionals such as data analysts and process analysts perform business analyst activities in their daily work, many organizations employ a dedicated business analyst. In fact, there are sub-types of business analyst roles that focus on IT, for example, or a business systems analyst. One can also become a senior business analyst.

Key skills:

Creating concise requirement documents for improving processes and implementing technology solutions that help meet stakeholder needs.
Data visualization and other visual modeling skills that help to capture and convey information visually.
Ability to form strong relationships with stakeholders.

The median business analyst salary is $59,291 in the U.S.

Closing Thoughts

While sales development, business development, and business analysis involve distinct roles with specific skillsets, there is an overlap in many areas. Sales development and business development are closely linked, as are business development and business analysis.

There is, therefore, the opportunity to carve out a career path starting with becoming a sales development representative, moving to business development, before upskilling to become a business analyst.

Does Agile need Architecture to be successful?

EA Learning — Wed, 24 Jan 2018 03:21:00 GMT

On a recent Agile training course, the instructor opened the session by saying “Agile without a plan is just chaos!” I would like to propose that Agile without effective Architecture will eventually lead to chaos, particularly if organisations try to scale their Agile practices without some form of guiding framework.

The fundamental reason for this is that we all operate within constraints, which can be financial, regulatory, technical or customer driven. While Agile practices have traditionally been confined to software development there is a significant push by organisations, particularly at the Enterprise end of the market, to use Agile practices to manage traditional business functions. This new trend is euphemistically referred to as New Ways of Working. The benefits of leveraging Agile practices are numerous, with the fundamental benefit that organisations see Agile practices as a way to deliver improved outcomes for their customers and stakeholders, more efficiently and consistently.

There are numerous case studies citing the achievement of these benefits at a project level, but very few examples (to date) of successful Agile Transformations at Enterprise Scale. Proponents of Agile practices will point to the Spotify Model as proof that Agile Practices can be used to build a $13 billion Enterprise. Which is true, however, they didn’t do it without Architecture. They did it by leveraging Architecture and its practices as an enabler and not a governing framework. The way that Architecture worked within Spotify is quite different to how Architecture currently operates within Traditional Brick and Mortar Enterprises.

It is very hard to find a clear definition of the role of Architecture in Agile. The SAFe (Scaled Agile Framework) framework has done the most to identify the role of Architecture within an Agile environment. As with all things Agile the focus is to create consistent value and Architecture is no different. In SAFe they define two distinct elements of Architecture:

Emergent Design
Intentional Architecture

Emergent Design provides the technical basis for development and the incremental implementation of initiatives. It helps Designers and Architects to be responsive to changing customer/ stakeholder needs to ensure the initiative continually delivers value. At this level, SAFe practitioner’s see Architecture as a collaborative and interactive exercise through which the design element can emerge.

Intentional Architecture is a much more structured approach and more aligned to what many would identify as being traditional Architecture, that is a set of defined and planned Architectural initiatives which will both support and enhance the performance and usability of the initiative. In effect, Intentional Architecture is a clear recognition that we all need to operate within certain constraints such as choice of technology platform, financial budget, etc. If these constraints can be identified and incorporated into the initiative then the probability of the initiative being successful and delivering value is increased.

SAFe practitioners proport that by balancing Emergent Design and Intentionality Agile practices can be scaled to deliver Enterprise level solutions. In Safe, this combination is referred to the Architectural Runway which provides the technical foundation for creating business value. Which is in complete alignment with traditional views of Architecture.

The key to the success of this approach is the level of abstraction at which the balance of Emergent Design and Intentional Architecture occur. The fundamental behaviour that will determine this is collaboration. Architects need to be able to work productively with Agile Teams to provide fast and local support to manage Emergent Design while also helping Agile Teams to appreciate and navigate the constraints defined by the Intentional Architecture. One of the key attributes of Agile Practices is the fact that Agile Teams are encouraged to provide constant feedback to their stakeholders. As emergent designs develop Architects can use this information to adapt and develop the Intentional Architecture to ensure that the overall Architecture of the Enterprise is evolving with the organisation in the medium to long-term.

So does “Agile need Architecture to be Successful?” I would say the better question is “What type of Architecture does Agile need to be successful?” Agile requires Architecture that supports the way the Agile Practices deliver of outcomes (value). The type of Architecture that will do this will be a combination of a nimble reactive style of Architecture supported by a more traditional structured approach to Architecture. The challenge as with many things is to get the mix right!

Written by Scott Comte, General Manager of EA Learning.

To find out more about the EA Learning Business Architecture or Agile training courses please fill out the below form or click here to view our course range.

A New Metaphor for Business Analysis

Ronak Sanghavi — Sun, 25 Jun 2017 17:29:00 GMT

Current State

For many years now, the most commonly used metaphor on Business Analysis has been the “Bridge”. However, in recent past, some in the BA community have started revisiting the metaphor resulting in a debate on how relevant it is. Of course, the value business analysis can provide for an organization does not depend on how it is described. So does that mean we should ignore this debate? I don’t think so. A metaphor is a powerful tool to develop useful mental models, and efficiently create possibilities for value-creation.

My take on this debate is that both sides are right. This is so, because the state of business analysis is not uniformly mature across countries and work cultures. For instance, BAs in North America are more likely to find the “Bridge” metaphor limiting/restrictive because of how the role has matured in the past decades. On the other side, for most BAs in emerging economies the “Bridge” metaphor still provides aspirational value.

So, what is behind my ambivalence? Most common interpretation of the metaphor is that it connects business and IT stakeholders. My take is that it is a bridge between the problem domain (current state) and the solution domain (future state). This take on the “Bridge” metaphor is not limiting, because it includes all levels of business analysis maturity - from strategy analysis to solution evaluation, and everything in between.

A New Metaphor

Not that there is anything wrong with a debate, but it is time for a new metaphor. I would like to share with the BA community a metaphor which has shaped my business analysis journey, especially in the past 5 years since I co-founded a business analysis startup. I look at business analysis as a “GPS” to move from the current state to the desired state. In other words, it guides stakeholders to achieve project success and organization goals. This metaphor is more inclusive (represents all flavors of BA role) and accurate (represents full potential of the discipline).

Let us look at the elements (features) of the conventional GPS system, which make it so useful; and how business analysis aligns with them.

#	GPS Feature	How Business Analysis aligns with GPS Feature in Projects
0	MAP – a useful representation of the landscape	· Build a representation of the business and IT landscape through research and analysis of industry; market forces, including competition; organization; operations; and current IT systems
1	CURRENT LOCATION – ability to determine current location in the context of the MAP	· Provide appropriate context for a project by customizing and sharing with stakeholders the relevant business and IT landscape · Define current state of the problem domain, and frame the problem statement
2	DESTINATION – assistance to select destination, e.g. a highly rated Point of Interest	· Help organizations prioritize IT investments through business cases · Facilitate definition of the desired state through solution scope and requirements specifications
3	NAVIGATION – real-time navigation to help reach destination most efficiently	· Facilitate selection of the best solution to meet requirements · Facilitate shared understanding of requirements through requirements transition, continuous communication, traceability and change management · Identify, engage, collaborate and coordinate with stakeholders; and support them to achieve desired solution

Any single feature, from the list above, is useful by itself. The “GPS” metaphor on business analysis is inclusive and aspirational enough regardless of the maturity of the BA role in a country, work culture, organization, or even an individual project. Furthermore, by symbolizing the positive global impact GPS has had on humanity, this metaphor helps us quickly and robustly communicate the power and value of the business analysis discipline.

My Experiments with this Metaphor

The “GPS” metaphor is not just a concept, which I made up for the purpose of writing this article. This mental model has fueled my passion, and shaped how I have approached business analysis in the latter part of my career. In fact, all service and solution offerings of my company are built on this mental model. I have received favorable and instant acceptance of this metaphor every time I have pitched my company’s solution portfolio to potential clients. I have also received positive feedback in training and coaching interactions from individuals when I have used this metaphor to provide more clarity about business analysis.

Your turn

I would love to hear your views on this. I hope that your active and constructive participation in this dialogue will not only help me crystallize my thoughts on this topic, but also give the BA community a new metaphor to actuate and communicate the potential of our profession.

Challenges in Implementation

Sanjay Yadav — Mon, 20 Mar 2017 12:34:00 GMT

Challenges in Implementation:

I’m a strong believer of putting finishing touch to any initiative. Project Initiation is always tough and complex and need lots of research but if BA is unable to give the finishing touch then he is not done yet. So, I thought to put few of my views, challenges and observations during Implementation phase that I have faced. BABOK does a great job in explaining the Strategy Analysis and Solution Evaluation however real time challenges are most of time unspoken. As a Product based Business Analyst I often face few challenges which are altogether different than the last one.

Stakeholder involvement and Governance: This is one of the challenging and critical step to find out the exact governance of stakeholders. Each stakeholder interest towards the product implementation do impact the final stage of the product. Lack of interest do hamper the product implementation. So if any stakeholder has less interest so its critical to know the reasons. Sometimes its better too to know why if any stakeholder shows more than needed interest. Maintaining correct and verified Project Charter does help in this.

Over Expectation: Customers are always demanding and they should be as they are the one who are paying for all these, however as a Business Analyst you must be very smart to distinguish the expectation and over expectation of client because over expectation often makes your system more complex to use by the end-user and customer which ends with spending more bucks and gaining less.

Deadline and Release Planning: As a business analyst make sure that circumstances don’t control you and your team, and you deliver your project successfully even if you don’t meet the original deadline. The art of prioritizing the solution requirement helps you to pass through. You should keep some time in buffer so that you have availability of resources to fix the unwanted issues or the deadlock condition in approval or implementation.

The Acceptance: Most of the time I have found more involvement of people in acceptance compared to when you do the brainstorming or focus group. Sometimes customer say that they aren’t looking for this altogether. So, providing a view of your product before acceptance saves you. Do not ever try to give more than requirement (without information), customer will treat it as a bug because they haven’t requested it. Though sometimes over-explanation saves.

Training: Sometimes it happens that everything is as per the client request and you are at a better stage to close the project but you end with hearing that there is no such benefit by the new implementation. I have observed that sometimes the user is not aware of the new feature or do not know how to use the new feature at all. So, Training to right people is very important. Sometimes you should move desk by desk to see if customer the using it fully.

Getting feedback: Learning from your mistake is very important however knowing what went perfect is important too. Feedback from customers is very important to learn and grow as a business Analyst.

There are number of other challenges that do a Business Analyst phase. I would love to hear.

How A Dentist Appointment Made Me A Better BA

rlogan1301 — Tue, 17 May 2016 16:36:00 GMT

My youngest daughter was scheduled for her first dentist appointment. She couldn’t contain her excitement. She had her stuffed dog, dentist-visiting attire and bright, sparkling smile ready for the event. She was ready to go. Little did I realize that not only would my daughter come away with a clean-bill of dental health, but that I would come away a better business analyst as a result.

1. No pre-conceived notion – My daughter was excited with no apprehensions and no self-fulfilling prophecies to sway her. She had no idea what it was going to be like nor did she hold any opinions on the matter. She just knew that her older brother and sister went regularly and now it was her turn as a ‘big girl’ to go to the dentist! Kids are not born with pre-conceived views of the world. Most of what they experience is a surprise (pleasant or unpleasant) and an adventure. As adults, we have lived through many different experiences and as such, some of us dread going to the dentist. As a business analyst, we deal with pre-conceived notions on projects all of the time. End users, sponsors, subject matters experts all have some sort of view or opinion on the purpose (goal) of the project. Some views are positive (end users are really needing this enhancement) where other users are skeptical or out-right negative/cynical about the purpose. As a business analyst having a view or opinion of the project is ok, but I find one is far better served to suspend all judgement…the success of the project increases when the business analyst leaves his\her views at the door.

2. Curiosity - One of the results of my daughter’s experience was a ton of questions directed at me. “Why do you have to sit in a long chair?”, “Why does the doctor wear a mask?”, “Why do I need my teeth cleaned?”, “why?”, “why?”. Some of her questions may have been her wondering why I would do such a thing as to send her to the dentist, but I think most of them were simply driven by her basic and innate curiosity. In my opinion, curiosity is the foundation of a business analyst. This curiosity is the driver towards discovering root cause within a project and ultimately providing that “what is the problem we are trying to solve”…the real ‘a-ha’ moment. I have been on projects where, as a result of the “whys”, it was discovered that a technical solution wasn’t even needed and that a change in the business process, communication method or organizational structure would better solve the problem.

3. A constructive Lack of Inhibitions can go a long way…not being afraid to ask questions and not being reticent about not knowing the answers – after answering the litany of “why” questions thrown at me I came to realize that she was very courageous to even ask these questions. She wasn’t afraid that her questions may change my perception of her and she wasn’t afraid to challenge her father or the situation. Having the courage to ask “dumb” questions (even after being told there are no dumb questions) drives the conversation forward. It also encourages others to ask “dumb” questions because then, the underlying foundation for “if he can ask that then I can ask this” leads to better discovery and understanding.

4. Celebrate a Milestone - after her appointment what is a father to do? You guessed it...take her to get ice cream. Am I going to win father of the year? Probably not, but I wanted her to celebrate her first dentist appointment and her conquering something that was unknown and, possibly, scary with a positive “end note”. Participating in a requirement(s) sessions can be an unknown adventure that is both challenging and rewarding. Recognizing the successful completion of requirements for a project is a big deal and, as a business analyst, you should bring to light the major accomplishment (milestone) that it is. Do you need balloons and catered hors d’oeuvres? No, but explaining how the completion of this milestone will foundationally impact the rest of the project goes a long way.

I didn’t expect an innocent visit to the dentist office with my youngest daughter could correlate so closely with my daily challenges as a business analyst and provide me such insight into my profession, yet I remain grateful for the education and perspective I gained. I wonder what I shall gain in the years to come from similar experiences? I’m hoping I find such introspection and edification when the time comes for her to venture into orthodontia for braces.

Randall Logan is the President of PushPull, LLC (www.pushpulltech.com) a management consulting firm in Indianapolis. Randy has over 18yrs experience as a business analyst, project management, process analyst and consulting within the retail, manufacturing, finance, high-tech industries and can be reached at randall@pushpulltech.com

Research: Roles and background before becoming a Business Analyst

Trividh Patel, CBAP — Mon, 11 Jan 2016 02:28:00 GMT

I am pleased to share the analysis of a Qualitative Survey to understand the backgrounds of Business Analysts (BAs) and the roles they have held prior to becoming BAs. This survey was conducted as an informal poll on LinkedIn. The numbers of participants are over 250 and hence are statistically significant to infer.

Inferences

Developers/ Programmers are the highest to become BAs (most of them after becoming a Tester, QA Analyst, Systems Analyst, or Project Manager).
Business side Subject Matter Experts (SMEs, including end-users) are the 2^nd highest to become BAs (some of them after becoming Tester or Project Manager).
Project Managers and Systems Analysts are the 3^rd highest to become BAs.
MBA and Bachelors degree in Information Systems has helped to directly become a BA.
People with other roles/background that have become BAs include
- Testers and QA Analysts
- Application Support and Customer Support
- Sales, Marketing and Relationship Managers
- Data Analyst
- Technical Writers (including those working on proposals)
- Technical SMEs (Implementation/ Configuration Analysts)
- Project Coordinators

Conclusion

People from diverse backgrounds (technical, business, support etc) and roles have become BAs but there is no one particular path that can suit all, hence your own efforts and hard work will get you where you want.

About Author

Trividh Patel, CBAP® has well over a decade of experience in an IT services industry, in various functions such as Business Analysis, Business Technology Services, Presales, and Project Management, primarily in Banking, Financial Services, and Insurance domain.

Trividh has done his MBA from JBIMS, University of Mumbai, and Bachelor of Engineering from VJTI, University of Mumbai.

Trividh Patel, CBAP® provides specialized Business Analysis Trainings, such as

1. Fundamentals of Business Analysis
2. Mastering Use Case Modelling
3. CBAP® / CCBA® Certification Prep Course

Trividh Patel can be reached on -
LinkedIn: http://www.linkedin.com/in/trividhpatel

How To Effectively Use Observation in Projects

Fareed R — Fri, 20 Mar 2015 05:59:00 GMT

Internships can provide some great learning opportunities. I was lucky enough to learn one of the best lessons on the first day of the very first internship of mine. My mentor at the time asked that, for the first 4 weeks, I invest time in every aspect of his business to learn how everything functions. I thought he was insane yet it was one of the best lessons a college freshman could learn – by observing.

When it comes to projects, Stakeholders usually find it hard to explain what their job is or what the requirements are. So by observing and asking questions one can find out a lot more like the flow and sequence of the activities. Observing can happen passively (by quietly watching) or actively (by engaging with the stakeholder through the entire process).

The best way of capturing the activities, steps and decisions is by using a process flowchart or activity diagrams, also known as lane diagrams. Process modeling is a visual representation or the activities and swim lane diagrams shows these activities and captures the people who perform them. Each person has their own lane so it shows how the work is passed from one person to another.

When my 4 weeks were complete I fully understood how the organizational groups and processes fit into one another. How everything got together and how the products were developed, manufactured, configured and shipped.

Here is what I recently learned through observations in the designing requirement phase of a project.

Firstly define the best conceptual design while staying within the project scope and fulfill the business’ and users’ needs.
Review each step and find out what is working, what they want to keep and what they want to remove or what needs to change.
Start planning once you have all the information.

I am very grateful to my mentor for the internship experience and that, as a professional, I can now understand the value of watching people and processes in action.

More training on: https://www.udemy.com/business-analyst/?couponCode=BusinessAnalystSocialNetwork#/

Is it just me, or do I really dislike BA work?

DMLeVoir — Tue, 06 Jan 2015 15:29:00 GMT

I was lucky enough for awhile to do very technical systems analyst work. Now I am only given what I suppose are traditional BA assignments. I find the work boring, tedious, uninspiring, and most of all I feel unappreciated and undervalued. I feel like a glorified secretary - I take notes and write up requirements or meeting minutes, send them out or meet again, and everyone dumps on the work I've done. There is no way I can know what people want if they don't tell me, and I don't think my job is to put my own thoughts into things. I am discouraged greatly that all I seem to be doing is writing things down other people say, then they get to revise it and make me do it over again. I never get the satisfaction of doing something well and having it be "done" - someone is always adding or revising.

What can I do to understand if this is just me, or is this the true life of being a BA?

What do you do?

Pjbussol — Mon, 18 Nov 2013 23:14:00 GMT

“So, what do you do?” It’s quite probably the question I most dread being asked. It’s a fairly benign question but as a Business Analyst I feel compelled to assess and understand what I am really being asked before attempting to provide an appropriately pitched response to my inquisitor. I find myself scrambling for the right words whilst my inner-voice is assuring me that whatever answer I give will most likely be met with confusion and probably even a little irritation.

“I am a Business Analyst” I awkwardly mumble – blushing out of embarrassment for the both of us – whilst preparing for the inevitable follow-up question…. Don’t get me wrong, I love my job and can passionately talk about it. The problem is, unlike a Project Manager, for example, the role of a Business Analyst is not clearly defined – You've got to love the irony!

The Business Analysis Book of Knowledge (BABOK) includes a standard definition of what a Business Analyst does. However, every Business Analyst, Project Manager, Hiring Manager etc. will have their own understanding and set of expectations. The truth is I don’t do any one thing. On any given day I could be mediating a heated discussion between a solution designer and a CFO in the morning and in the afternoon ordering doughnuts for a design workshop (tip: a great way to prevent any future mediation!) Sure, a Business Analyst needs to be skilled in lots of things and may be accountable for producing this document or that document, but these things should not define us and are poor indicators of the value we bring to a project. Every successful project starts with an idea but what is ultimately delivered is often very different indeed. The idea matures and flourishes and it is the job of the Business Analyst to cultivate and manage this change. We navigate the project through its life-cycle. The Project Manager might be in the driving seat but we are certainly up there next to her, preempting bumps in the road, managing diversions and ensuring the passengers in the backseat continue to enjoy the ride. For me, being a Business Analyst is much, I imagine, like being a parent to a teenage son or daughter – we must be objective listeners, excellent negotiators, understand budgets, have a real grasp on finances and build strong relationships (sometimes with people we don’t necessary want to). We are protective, we are demanding, we are challenging and we are 100% invested in the success of our “babies”.

“So, what do you do?” it’s still a question that I dread being asked, but honestly, I normally just respond with “I work in IT”… That’s normally enough to stop any conversation dead!

Negotiation skills – are they really for Business Analysts?

David Wright — Fri, 13 Sep 2013 01:10:00 GMT

I keep seeing in BA skill descriptions or in specific articles that ‘negotiation skills’ are a necessity for Business Analysts. I just don’t see it myself. Negotiation is a difficult activity for many people, and I see this trend as an attempt to offload negotiation to other people… like Business Analysts.

Why do I feel this way? As an activity, ‘negotiation’ is when people with differing needs but overlaps in other areas (like sharing resources and money) need to reach an agreement that helps them in some way while giving up something in order get that agreement. In business, and especially IT, the need to reach such agreements occurs all the time. It often looks like this: a business unit has objectives to reach and a certain budget, and they need enhanced/new systems to reach the objectives. IT has the resources and tools to do the work. Both have useful but always limited assets.

In this situation, Business Analysts have no assets to negotiate with, what BAs bring to the table are analysis skills. It is the business and IT that need to negotiate an agreement about money to be spent on IT activities, including what the business gets for their money, and when they get it by. Business Analysts bring enough detail and clarity to these points so that both parties are happy; the business is able to define what they need, and IT is able to say what it will take and how long it will take.

The nature of limited resources and increasing time-to market pressures will almost always result in the business wanting more they can afford and/or want it sooner than it can be delivered. This is usually where ‘negotiation’ is said to occur by Business Analysts, but it only happens if one of the parties offloads their participation to the BA, who is told what to offer but has no real authority to bargain.

The better situation is where both sides remain engaged and the BA uses techniques like prioritization to help reach an agreement on acceptable deliverable for a feasible price and time. All through this, the BA is a ‘facilitator’, not a ‘negotiator’. Smoothing the way to agreement makes life is easier for the real negotiators; if we BAs do our jobs well enough, the involved parties will never even know or feel that they were negotiating!

Would Indiana Jones be a good Business Analyst?

Dean J. Chapman — Mon, 24 Jun 2013 17:56:00 GMT

You might think I am crazy for wondering if Indiana Jones might be a good business analyst. Even though Indiana Jones is portrayed in the movies as a treasure hunter, he was really an archaeologist first. So what skills do archaeology and business analysis have in common? I don’t think I would have been able to draw a parallel between the two professions until I had this experience during a recent project meeting at a client site.

The tone of the meeting was very tense from the start. All of the key project members and stakeholders had been gathered in a conference room to determine how we could deliver the impossible on a very tight project schedule and when it appeared that we didn’t have all of the necessary information and data. There were a lot of heated discussions about how to solve this problem including numerous very serious mentions of delaying the project and using the additional time to produce or reproduce the missing information and data.

Then, as the problem was being rehashed for what felt like the millionth time, a light went on in the head of one of the business SMEs and they blurted out “I think we have that information! I remember a few years ago when we did a system upgrade and I know we were required to create documentation for our department that contained some of that information. I think it’s in our current document library but I haven’t looked at it in years.” Then a business analyst on the team chimed in “Yes…I remember seeing similar documentation in a folder on our corporate shared drive when I was digging around for another project….but I can’t remember where I saw it. A lot of that old documentation was recently archived to another location.” Next the software development manager spoke up and said “We had a vendor help us with that upgrade, I bet some of the information we need is in the documentation provided by the vendor during that project. We just have to find out who has the documentation.”

As more people joined the conversation, it became clear to me that the information and data probably existed but over time had been forgotten, buried, hidden, or possibly even lost. We hadn’t uncovered the Holy Grail but we did discover some things that could be used to move the project forward. At that point I leaned over to colleague of mine and said without any real thought “Sounds like we needed an archaeologist on this project!”

When I returned to my desk after that meeting, the idea that the project could have benefitted from having an archaeologist stuck with me so I googled archaeology. I wanted to know why archaeology sounded like something that fit as part of the job description of a business analyst. Here is the definition of archaeology I found that resonated with me.

Archaeology is the study of human activity in the past, primarily through the recovery and analysis of the material culture and environmental data that was left behind, which includes artifacts, architecture, biofacts (bones or seeds), and cultural landscapes (the archaeological record).

When I read that definition, I couldn’t help but immediately make the connection between archeology and business analysis. As a business analyst, I usually find myself digging through every part of the organization trying to uncover information and data that was left behind that could be valuable to my current analysis. I comb through binders of documents that I find in empty cubicles or in rows of filing cabinets in dark hallways. I spend hours searching through obscurely labeled folders in corporate shared directories or on the corporate intranet. I talk with individuals in the organization who have been around for a while or who could have “tribal knowledge” about where the information and data I am seeking might exist. I search everywhere and try to leave no stone unturned. The information and data I am seeking is in the form of artifacts (strategic plans, organization charts, business processes, use cases, data models, business rules, etc.), architecture (frameworks, models, blueprints, etc.), biofacts (skeletons of successful projects or projects that were never completed), and cultural landscape (historical record of the organization and how it has changed). In many ways, I feel like an archaeologist…a business archaeologist!

Don’t get me wrong, I am not saying I could do what Indiana Jones does and I am not yet convinced he could be a good business analyst. What I am saying is that there appears to be some synergy between what archaeologists and business analysts do. We both search for those hidden or buried treasures that will help us know the past, understand the present, and build for the future.

Now if you agree that part of our role as business analysts is doing some archaeology, then I want to leave you with this question. How do we emphasize that the focus of doing “business archaeology” should be to uncover the information and data necessary for a thorough and complete analysis and not to create or recreate information and data that doesn’t exist or won’t add value? I don’t recall Indiana Jones ever making up or creating a relic because he didn’t find one during his search (unless, of course, he did it to fool one of his arch nemeses so he could escape). I am not sure how to answer this question, but if you are like me then you have been involved in many projects where there was more emphasis and time put on creating “as is” documentation than actually doing analysis and providing real value to the business. Your thoughts?

Dean J. Chapman

Sr. Business Analyst/Business Architect

sr.bus.analyst.63@gmail.com

How to convince stakeholders of BA value for the first time?

Lee Grinberg, CBAP, PMP — Fri, 21 Jun 2013 13:46:00 GMT

In my previous posts I outlined how I was able to succeed being the first and only BA at a company and the importance of establishing trust between you and the stakeholders.

So you're the first BA at a company. All are looking at you and thinking what can this person do for me?

Good question. What can you do for them?

Show them how your contribution will make their life easier!

I'll tell you how I handled this challenge. I was brought in to write functional specs based on business requirements. The business requirements were good but not complete. The IT folks were afraid that key use cases were missing.

I took the following steps:

Created a context diagram (first one in the company) to show them what scenarios may be missing
Created use cases from the business requirements
Reviewed both with the SMEs. This uncovered many gaps not covered by business requirements

Once gaps were uncovered, the people writing the business requirments were relieved to know the gaps were identified early in the process and not in a later (embarassing) stage. I made their life easier and this was appreciated.

The next steps were around design:

Wrote a detailed functional spec outlining database and functional changes
Clearly wrote out testing scenarios

So what, you may be thinking. After all, this is what BAs do. True, but remember, I was the first and only one in the company so no one was convinced of the value of a BA.

The result of design was that developers were relieved to know they didn't have to have lengthy conversations with the end users about functionality.

The key concept again is to make their life easier!

Once trust is established, however, you must prove that you can benefit the stakeholders.

Which seat is mine?

KMUK — Mon, 16 May 2011 16:16:00 GMT

I've been working with a company now for a little over a year as a contract business analyst and I think it's fair to say that they are still evolving their understanding over how to effectively utilise BA's like myself. So far, i've been fairly successful in deploying methodologies, BA tools and techniques, but i've been perplexed over opposing views about where i should physically sit when it the office - with the IT team, or, 'the business' team.

Personally, I feel that building relationships with the end-customer is vital in a BA role, and with this in mind, I have worked hard at spending the balance of time with 'the business' and this has delivered great results in the projects I have worked on. This is somewhat of a rarity between the IT and 'the business' in this organisation due to the typical 'them' and 'us' approach which stifles progress.

My concern is now that i feel under pressure to spend more time with the IT folks, which i really can't understand the drivers for. I had one comment about being "too business orientated" but there is absolutely no basis for this - I suspect this stems form a touch of ignorance from IT that they are always right and are not interested in the business view of things (plus, have no regard for the very role the BA is trying to perform.

Am i missing something here? I'm kinda stuck between sticking to my guns - which is a proven approach and builds a bridge between the two functions, or, relenting - spending more time with IT and potentially jeapordising the delivery of the project. Ironically, the person that signs my invoice is the individual applying pressure.

Any views welcome!

BA Careers - Is industry experience more important than Analytical skill?

HSantanam — Mon, 06 Dec 2010 19:32:00 GMT

Business Analysts often delve into business requirements, gathering, understanding and documenting business processes and functions. An analytical mind and detailed information gathering are considered to be essential; one wonders though, if industry experience is a must for good business analysis skills. After all, if you knew well the ins and outs of the industry you were in, that’s good, right? The answer is probably, but not always. Why is that?

Business analysts, like developers and solution architects, are trained to think logically and focus on specific issues at hand. Once in a while, though, they need to step back, and like a painter evaluating and assessing his painting-in-progress, assess their progress on the task at hand and be prepared to explain it to a wider audience in plain talk. That, in my opinion, is an essential skill of the modern analyst.

First, industry experience means less time is wasted knowing the industry environment – the general models the business follows, what regulatory and competitive arena it is part of and some common terminology. Secondly, business process flows are easier to understand, say, if one was documenting business process flows for a financial transaction, if that person had already worked in a financial services firm in a financial transaction environment (e.g., Front office, where the deals were made, or the middle office, where financial and regulatory processes were checked or filtered, and the back office, where the transactions were processed and settled – and where exceptions were followed up for closure).

That of course, brings up an interesting question – if a business analyst goes into an unfamiliar environment, how much time should be spent learning the business environment? Wouldn’t that leave less time for focusing on the essentials of requirements, elicitations and documentation? And how valuable would all that be, anyway? After all, time is money – and with workloads being what they these days, such knowledge, while good for a progressive and open mind, would be quite expensive indeed, wouldn’t it?

The answer is that depending on the timeframe, it would be beneficial to get the most important work done first, which would mean skipping the overview on the business. In a limited time frame, a “bullet-point” information dissemination method (summary) might work. Asking questions in the right environment is healthy, but learning important concepts on one’s own time is a better idea. After all, stakeholders have limited time available even for requirements – they might not have the patience for an extended basics class. On the other hand, workflows and the reasoning behind them should be questioned to extract the maximum value for optimization and better business.

What about the times when it might be beneficial to hire a business analyst who is sharp and curious, but not industry-knowledgeable? When the existing patterns are so constricted and “inside the box” that a fresh perspective is needed, hiring analysts without a lot of presumptions and insider’s knowledge is actually a good idea.

I worked in a firm once where I was asked to interview, evaluate and recommend IT candidates (mostly developers, some analysts). At the end of the face-to-face interview, I would ask the candidate to solve a problem on pen and paper. The rules were clear – no writing code, simply writing out the solutions – a diagram was acceptable as long as it wasn’t too complex. Additionally, the answer had to be limited to 1 page and be completed in about 30 minutes. I was amazed at how the smartest candidates failed this written “test” – it was actually quite simple, for it did not require deep industry knowledge and did not put the candidate on the spot by testing coding knowledge. I simply wanted to know how the candidate thought about solving problems and whether he/she was able to put it on paper. I often got several pages of answers, written code and requests for extending the time available, though all the requirements for the written test were explained before hand. Needless to say, these candidates were not hired.

Moving to Agile Documentation – why ‘Pair Inspections’ make sense

FergalMcGovern — Wed, 03 Nov 2010 11:00:00 GMT

One of the more controversial techniques fostered by some in the agile community is ‘Pair Programming’. It is a practice that originates from Extreme Programming, a specific Agile process pioneered by Kent Beck.

It is controversial, particularly for larger corporates because it seeks to adjust human behaviour patterns. In Pair Programming, developers sit side by side, sharing one machine and working in teams of two at all times on a single code base. In reality, it is one of the agile techniques that is likely least adopted and most controversial among programmers for a variety of reasons, mostly cultural and behavioural in nature. Most fundamentally, for a team to be successful at pair programming takes a lot of hard work. It’s a bit like a marriage really, personality compatibility is a key pre-requisite and just like marriages, the best work well but not all will be successful.

Pair Programming in action

The point of this post is not to get into the specific argument as it relates to agile developer activities for code, but rather to propose something that Project Managers and Business Analysts should actively consider for documentation and that is what I will call ‘Pair Inspections’ or PI.

The issues I have found with larger document sets in lager initiatives, especially larger documents such as BRDs and Detailed functional specifications and Test Plans is that they are:

generally authored by one and only one person with one vantage point
are worked on for a concentrated period of time by one person
do not combine the considerations of other relevant stakeholders
if inspections are going on, they are at a particular point in time, typically at a phase gate and are not that effective at spotting real issues. Infrequent code inspections suffer the same fate in my experience, if I reflect on my time running engineering teams

Now, I am not suggesting that we have co-authoring sessions for a single document. The nature of MS Word and the fact that many people are distributed make this in many cases impractical.

What I am suggesting however is that documents are reviewed actively & informally as part of the authoring & document production cycle. Let me suggest some simple measures that would achieve this:

Frequency: Conduct a Pair Inspection once a week. This may be ‘analysis phase’ in waterfall, or pre-sprint stage in Agile
Alternate stakeholders: Every other week try to include a stakeholder who wears a different hat, e.g. pair a BA with a Test Lead, pair a BA with a PM
Distributed Teams: For distributed BAs working in remote locations, use collaborative tools such as webex, gotomeeting or livemeeting.
Consistency: Put a solid recurring meeting in your calendar every week at the same time and take it seriously
Informality: Make pair inspections a way to gel stakeholders. Don’t impose rules but let the inspection process ‘self-organise’

The net effect is that substantially better documentation results when active & collaborative inspections and reviews occur, regardless of whether you are in a waterfall or agile environment.

Applying the above simple steps tightens document quality in very material ways.

------

Fergal McGovern, Founder VisibleThread.

See our main blog at: http://www.visiblethread.com/blog/

Enter the Business Engineer: Part 2

Mendix.com — Tue, 19 Oct 2010 19:36:00 GMT

In a previous post regarding the emergence of the Business Engineer, I discussed the Who, What and Why of this new type of human capital. At Mendix, we see them growing in numbers, most likely due to the nature of our software. If you’re going to give business analysts the ability to develop software, or developers the ability to communicate business – you’re going to see doors open and walls collapse on either side of the business-IT equation.

The BA

In order to figure out exactly where BE’s come from, so that we can harness their powers for the greater good of business agility, we’ll have to know more about their closest relative – the BA. According to The International Institute of Business Analysis, the role of a business analyst involves: “the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization and to recommend solutions that enable the organization to achieve its goals.”

Well isn’t that something. All of those tasks and techniques are funneled down into a recommended solution and passed along to the technical wizards who turn requirements into reality. I’ve always wondered whether the less-than-technical BAs wish they could, perhaps just once, finish the job and deploy an application. Perhaps they’d hate to deal with code, I’m not sure. What I am sure of, however, is that business engineers dream about models (business-models, pervert!) and how great it would be if they could get requirements and deliver solutions, on their own.

The BE

Call it selfish; call it futuristic; you can even call it a pie in the sky. With the emergence of the business engineer, demand for agile software development, visual modeling tools and a revamped SDLC is truly explosive. Based on the definition above, the BE is not really related at all to who we now know as the business analyst. Though I mean not to offend nor aggravate business analysts or software developers, I must assume that they see the astronomies of their value propositions colliding.

So then, if the business analyst recommends a solution, it must be the business engineer who implements it. And if the business analyst plans the solution, the business engineer deploys it. I may even go as far as to say that business analysts identify the problem, where business engineers solve it. This fine, yet drastic and seemingly impossible, line – is growing in organizations everywhere.

What’s Next

As I mentioned in part one of this series of posts, the ambiguity of the business engineer is becoming more believable with every Mendix user. What was once called impossible by technologists is now championed as magic by audiences of our ‘proof’ of concepts, and we’re betting will one day be considered the norm in enterprise software development. In the meantime, collaboration between business and IT may remain segregated by occupational obstacles inherent to aging technologies and ancient practices.

The current generation of business and technology students is likely to pave the way for career paths in business engineering. Courses in business engineering will be taught by today’s business engineers, and until then, these heroes of enterprise software can only enlighten their organizations with a glimpse into the future of business agility.

IT Black Ops

Seilevel — Sun, 22 Aug 2010 23:26:00 GMT

I’ve worked on at least one project now and heard of several others where a super-secret development team works in parallel to solve the same business problem as the “official” IT project team. A coworker of mine coined the term “IT Black Ops” to refer to these sorts of projects where the business, either out of frustration, arrogance, or ignorance, hires their own shadow development team to implement a competing solution, or an enhancement to an existing solution. I’ve never seen this go well. However, unless you are at an executive level, there is very little you can do to shut down the black ops team. In many cases, you won’t even realize the black ops team exists until the last minute when you are forced to integrate their spaghetti code solution with what the actual IT project team has built. Of course, this kind of surprise is to be expected, since the very nature of IT Black Ops is to operate stealthily, and for their business owners to neither confirm nor deny their very existence. However, once their presence is detected, a project and budgetary train wreck usually ensues.

I’ve done a little bit of thinking recently about why IT Black Ops projects are launched in the first place. It’s probably because of one or more of the following reasons:

1.Low confidence that IT will be able to build something that actually solves a business problem. Sometimes this low confidence is warranted.

2.No budget to build something the “right way” (i.e., gather requirements, manage the project, test it, and deploy it).

3.Business owner finds an extra million dollars in the budget and can finally implement his/her pet feature, even though it was initially shot down because there was no ROI for it.

Lack of understanding about why it takes so long to develop working software.
Even though the decision for the business to go undercover with their IT development will likely be disguised, there are a few ways you can help prevent them from wanting to do this in the first place:

1.Keep the business engaged throughout the development lifecycle. Giving the business partial ownership over the project by having them sign off on and review working prototypes is a great way to give them confidence in the system and make them feel as though the solution is a joint effort.

2.Sell them on the value of process. The ROI for good processes is difficult to calculate; however, turning a team of developers loose to write code with no requirements or process discipline is about as successful as hiring a room full of 1000 monkeys to develop your solution. Giving the business ownership of the process will help.

3.Each project should have a clear ROI. This sounds obvious, but too many projects have a vision statement akin to “you know it would be really cool if…” People also become emotionally invested in certain solutions, without taking the step back and evaluating how well the solution solves a business problem. Just watch out for pencil-whipped and contrived ROIs. Be suspicious of any feature which does not tie back to a quantifiable business objective.

4.Use comparable projects to set expectations. People who do not work in software development often find it difficult to understand how expensive and time-consuming software development can be. This can sometimes lead to the attitude of “This is simple–I can do it faster and cheaper myself”. In order to head this off, it helps to show the budget, resources, and time to execute for similar projects. It is natural to ask the question “Why is it so expensive/time-consuming/so resource-intensive?” You can use the lessons learned on other projects to help answer this question.
It never really helps to mention that the black ops team will always fail, that someone will get fired if the black ops project continues, or that it will end up being more expensive in the long run–even though these statements are almost always true. Once the black ops team is hired, you’ve already lost, so do what you can to prevent IT Black Ops projects from being launched in the first place

This blog post will self-destruct in 500 views.

By Jhulgan

Want more? Check out our other posts here.

How many Business Analysts do I need on my project?

Seilevel — Tue, 27 Jul 2010 15:29:00 GMT

At the beginning of almost every project (and even sometimes midway through them) we are asked to create a requirements plan and estimate the time required on tasks and the number of BAs necessary to execute it. In a later post I’ll talk about the actual plan items, but we do have a rule of thumb for how many BAs you need on a project.

We have a standard metric we use: we suggest 1 BA can support 4 to 8 developers. Typically I suggest 1 BA to support 4 to 6 developers though, as 8 is a stretch on many projects. Of course this number is highly dependent on the context of your project, so treat it as a rule of thumb only.

As an example, right now we have 7 developers working on rebuilding existing functionality from an existing site and it’s required just over 1 BA to work on the requirements for it. And even at that, the BA is pretty stretched to get them done as fast as the dev team needs them. And in another part of the project, we have 1.5 BAs supporting about 4 developers who are doing defect testing – but they are also very intensely focused on UAT activities.

ByJBeatty

How many BA's do you need on your project? Do you have comments?

http://requirements.seilevel.com/blog/2010/07/how-many-business-analysts-do-i-need-on-my-project.html

Is Your Product Knowldege an Asset or Liability?

Seilevel — Wed, 14 Jul 2010 16:19:00 GMT

There was recently an interesting post by John Mansour on the Austin PMM Forum (registration required) discussing whether Product Knowledge was an Asset or Liability to product managers.

The author makes several claims about how product knowledge is a liability:

“In a nutshell, the more product knowledge you have, the less product management you’re doing because your product knowledge gets you sucked in to a plethora of non product management issues.”

“Furthermore, too much product knowledge leads to micro management – the kiss of death for anyone in a leadership role.”

“Detailed product knowledge = liability because you can’t see the forest from the weeds.”

“Detailed product knowledge = liability because it forces you more into ‘how’ features should work instead of ‘what’s needed and why’ from a business perspective.”

“The more you know about your product the more difficult it is to position its true value. “

I have to disagree with Mr Mansour that these are true liabilities, in the sense that the absence of product knowledge doesn’t truly mitigate the liabilities. Good product management is fundamentally about good product management.

It’s your job as a good product manager to avoid running down the ratholes that you could run down as a result of your product knowledge.

Post by MTalbot at Seilevel Inc

check out other blogs here.

“So, what do you do for a living?”: A BA/Product Manager’s guide to surviving cocktail parties

Seilevel — Thu, 10 Jun 2010 13:52:00 GMT

By Jhulgan

I used to dread hearing the question, “So what do you do for a living?” This was often usually asked by a family member or other acquaintances not familiar with the software development lifecycle, IT, or business processes in general. For business analysts, product managers, and other software requirements types, it’s difficult to give an answer without being convoluted or sounding like Tom Smykowski:

This great post expresses a similar insight beautifully, but many of us struggle with good, one-sentence responses to what it is we do everyday in simple English. I thought I would plagiarize some ideas that I’ve heard from colleagues over the years and compile them here:

“We help businesses figure out what software they need to build to solve business problems.” This is a personal favorite of mine that I stole from Marc (who posts under mtalbot on this here blog). It’s especially relevant to IT consultants/contractors. Just about everyone knows what software is, and a lot of people understand that just about every business runs on some sort of software to solve business problems.
“We help communicate the business needs of a system in a language software developers understand.” A variation of this is, “We translate from business to geek”, although I am less fond of the second version because it veers into Smykowski land.
“We make sure the right software is being developed at the right time, for the right people.” The emphasis here is on the right software. This response is nice because it allows you to segue adeptly into a discussion about business objectives.
“We help the business get the most value out of their development dollar.” This response stresses the fact that you are not just a scribe or secretary writing things down, formatting them, and delivering them to the development staff. You are helping make the tough decisions on which features to cut and which bugs to fix, and quantifying those decisions in terms of dollars and cents.
“We work with the business to find the appropriate scope of a software development project and ensure that what is built is what the business expects.” Whenever I am asked the dreaded WDYDFAL question, this is what almost immediately comes to mind. Sometimes I fill in the details of working with pictures to help model current business processes (and desired business processes).

So how about all of our readers? What answers have you come up with? Do you dodge this question altogether, or do you sound like a fumbling Smykowski? Hopefully we can all help each other find good answers to this question. After all, you never know when you’ll be in a meeting with “The Bobs” and the pressure will be on!

You can check out our other blog posts here

Humor: Project Management Speak vs. Business Analysis Wisdom

Martin — Thu, 13 May 2010 08:26:00 GMT

It is common for project managers to question the number of BAs they need on a project or how much time needs to be spent on analysis. The underlying concern seems to be a fear of “analysis paralysis”. Whilst not overtly stated, for many project managers, analysis is a necessary evil that if not carefully controlled, will delay the “real” work of writing the code and delivering the system. No doubt this view has some basis in their past experience of using BAs. However, an examination of common project management proverbs and folklore might suggest the real problem lies in another direction...

Project Manager speak	Business Analyst Wisdom
The same work under the same conditions will be estimated differently by ten different estimators or by one estimator at ten different times	When the PM says this, get ready for him cutting your estimates in half
It’s just a small increase in scope	The most valuable and least used word in a project manager's vocabulary is "NO"
I told them we could deliver on time	Nothing is impossible for the person who doesn't have to do it
If you don't stand for something, you'll fall for anything (used after the BA questions the wisdom of a commitment given by the PM to the Project Board)	Exactly! (used by the BA in response)
Too few people on a project can't solve the problems - too many create more problems than they solve	So I guess we’re not getting that additional resource we need then?
A user will tell you anything you ask about, but nothing more	Exactly. That’s why you should have sent someone who would ask the right questions!
A user is somebody who tells you what they want the day you give them what they asked for	That’s what happens when you shortcut proper analysis
Of several possible interpretations of a communication, the least convenient is the correct one	Er..., how about asking which is the correct one? (Why are project managers so frightened of open, honest discussion?)
What you don’t know hurts you	What the PM doesn’t know usually hurts the analysts working for him
The conditions attached to a promise are forgotten, only the promise is remembered (when complaining about the Project Board)	The conditions attached to a promise are forgotten, only the promise is remembered (when complaining about the Project Manager)
The sooner we begin coding the sooner we deliver	The sooner we begin coding the sooner we deliver something the users don’t want and the later we realise the benefits due to the increased re-work
If you don't plan, it doesn't work. If you do plan, it doesn't work either. Why plan!	Answer: try planning properly
Project management is about balancing the triangle of time, cost and quality	Ever met a project manager with a good sense of balance?
When all's said and done a lot more is said than done	Not much hope of gathering detailed requirements then
I told the project board everything is on schedule	Bang goes my vacation!
We have successfully implemented the system with only a few minor teething problems	Yeah, teething problems like flaky performance, user dissatisfaction and de-scoped essential functionality

Blurring the Lines between Business and IT

Derek Roos — Thu, 21 Jan 2010 10:51:00 GMT

A “What If” question for business analysts and IT professionals…

What if it suddenly became very easy for someone to do both your job and their own, at the same time? If history provides any forecast for the future of IT, we are likely to see some interesting changes in the way human capital is managed – especially for those of us involved in the emergence of cloud computing. Clouds push complexity to the background and allow users to focus on what really matters: functionality and costs.

Have you ever noticed how the education we receive often sets boundaries in our career aspirations? We are trained to do something, and do it well – but in doing so, we take for granted the fact that others are doing the same thing in a different field. Then, when we are faced with an inevitable change, we instinctively take a “That’s not what I’ve been trained to do, there are other people for that” mentality. Sure, there are the motivated few who push down boundaries and become renaissance men and women in their own right. But when everyone else is set in their ways, these people are often considered a risk… think: too many eggs in one basket.

Now, to regress from my pseudo-philosophical banter, this trend is becoming all the more apparent as business analysts become more involved in technical training. Most IT veterans would say that business analysts will never have the true know-how to implement their plans, requirements and recommendations. The modern business analyst usually considers themselves more of a problem solver than a programmer – hence the separation of labor in this function of any business. Having surveyed the blogosphere for opinions of business analysts and IT professionals, there seems to be a live (and even a bit emotional) discussion between those who say it is a natural, and therefore inevitable, progression and those who say it is a “pie in the sky” and that it will never happen.

Contrastingly, a growing population of believers has something to say about the segregation of business and IT. In a world of zeros and ones, the innumerable coding languages can only become more and more efficient. As coding languages are continuously created, survival of the fittest can account for the extinct languages of modern programming. An abstraction of these languages is an ongoing phenomenon with a light at the end of the tunnel. Some say that using abstract, visual and human-readable models instead of low-level code is a very important step towards commoditized coding.

I’ve come to think about this abstraction phenomenon as measure to increase efficiency. When our ancestors realized that making bricks was faster than packing sand, they were on to something similar. If someone else uses molds to make perfectly shaped bricks that can be built into any structure, the workers need different skills but can ultimately build more economically, the architect can plan more accurately, and the buyer can move in earlier. So, why deal with sand when we can get the bricks from vendors elsewhere. Why deal with code, when we can get software modules elsewhere? This, my friends, may be the future of today’s business analyst. In the future, what if business analysts had the skill set and the molds to create bricks that satisfy their requirements without the need to deal with code – or sand?

Derek Roos
CEO
www.mendix.com

Raising the bar in Business Analysis and Internal Consulting

SmartProjects — Tue, 10 Mar 2009 04:55:00 GMT

Internal Business Analysis and Consulting teams are increasingly recognised as playing a vital role in delivering successful projects. More and more they are contributing to complex and strategic projects and performance expectations from executives are getting higher.

Are you interested in improving Business Analysis and Internal Consulting capability in your organisation?

I would like to share with you a new released video about "Raising the bar in Business Analysis and Internal Consulting".
It offers suggestion on what you can do to better prepare and develop your team and outlines a four-step approach to assessing and baselining your team's capability.

An Inquiry into the Roles of the BA and the BSA

Thu, 18 Oct 2007 00:15:00 GMT

How do we define the role of a BA. Is there a difference in responsibilities executed by a business analyst and business systems analyst? Or, are the titles simply synonymous with each other? Attempting to clear out some of that fog is the purpose of this article. As much as I enjoyed writing this, I also look forward to receiving your feedback and thoughts…keep the flow of information going.

An Inquiry into the Roles of the BA and the BSA

Firstly, I don’t believe the two terms mean the same thing; they are different roles, albeit entailing some very common responsibilities. The terms are used interchangeably all too often (I for one am guilty of that), implying the absence of distinction between the two roles. In actuality, the bigger picture shows a few, not a lot, but handful of noticeable differences. And sure, there might be more differences that I have not uncovered.

The way I went about determining the difference was to go on to Dice, and randomly pick out independent samples of the “business analyst” vacancies. I picked 30 of them – a minute sample size considering the greater population of 12,000+ vacancies. And I did the same for the “business systems analyst” job title. I examined the descriptions of all 30 posts in both groups, and documented and analyzed them (here, analysis wouldn’t have been possible before structured documentationJ).

Again, let me remind you of some pointers:

I picked out only those ads that said “business analyst” and “business systems analyst” as the Job Title and no other variations.
Ads were picked randomly, meaning I clicked on the ad without much thought, except the one above.
The one thought I did give was to make sure I wasn’t picking ads by the same recruiter (and it turned out neither of the samples had repetitions after all). Each ad was independent of the rest.

The summaries of the two groups have been attached below.

Apart from the commonalities that the two roles share (which is common knowledge), here’s what I found the differences to be:

At least 6 out of 10 business analyst positions require the candidate to have a good deal of project management knowledge, and will be expected to wear that hat as part of the of the responsibilities. This is a preferred skill for a minority of recruiters, for the rest it’s required. This area has major emphasis when BA’s are sought; they have to rise to leadership in the same position. Whereas for the business systems analyst, only four ads that mentioned project management skills. And even if they did, it was a preferred skill, not a required one.

More than BSA’s, BA’s are expected to have OOAD experience.

BA’s are expected to provide training to users, not just demos of the software developed. (I wasn’t expecting this; I’ve worked in places where a separate training dept. would take care of that.)

Experience with the UML was of greater demand from BSA’s than from BA’s.

BSA recruiters placed considerable emphasis on experience with Oracle and SQL, and design of relational databases. It’s almost like what project management is to the BA, SQL is to the BSA.

More than BA ads, BSA positions, albeit assorted, required knowledge of or experience with technologies like XML, Java, and UNIX.

In conclusion, except for # 3, the other differences couldn’t have been just coincidence in 30 distinct job ads. I think they are real differences and I’m sure there are a few more out there.

Attachments:

Summary of the BA ad

Summary of the BSA ad

Role of a Business Analyst

Priya — Fri, 03 Aug 2007 00:38:00 GMT

This article aims to share with the readers what it means to be a Business Analyst and people who are exploring this career path can hopefully gain some insight from this piece.

A Business Analyst is commonly perceived to be a ‘Conduit’ between the IT and Business units of an organization. Simply defined, a Business Analyst is a professional who carries out Business Analysis. Over the years, this role has evolved to more than just a ‘Translator’ of requirements. In the current scenario, BAs are involved in understanding business needs, problems and opportunities and providing recommendations and solutions to meet the business objectives, most of the times within the context of Information Technology.

The role that a BA is expected to play will largely depend on the kind of the project on hand and the IT team in place. The role of a business analyst is quite fluid and can assume different shapes based on the project requirements. Certain projects would require the BA to be savvy with the technology being used (although as a practice, the requirement gathering phase would be independent of the platform), while others like process reengineering projects may require the BA to be more of a domain expert.

Key Responsibilities of a BA:

The primary responsibilities of a BA across projects would comprise of all or most of the following:

Scoping the project: Understanding project scope and objectives. Ensuring that all the stakeholders concur on the scope of the project
Business Requirement Analysis: This process involves elicitation of requirements, analysis and Documentation. The BA is primarily involved in gathering, categorizing and organizing requirements into logical sections and then prioritizing them based on the business needs. Here the BA is also expected to provide value-add by helping business to analyze and prioritize its requirements to some extent. Business requirements are usually gathered through available reading material, user interviews, existing system documents, observations, group interviews etc
Requirement Specification and Documentation: Requirements documentation will form the backbone of the project, as all further development will refer to these documents. Requirements could be represented by way of BR documents (in plain English), visual diagrams like Use Cases, Process Maps and Data Flow Diagrams depending on the audience that is going to consume these documents.
Coordination with the development team: BAs are also expected to liaise with the development team to ensure that the requirements are correctly understood before the development of the system begins.
Testing: BAs are also usually involved in Unit Testing, Integrated Testing, Functional Testing

Knowledge and Skills required:

Business Requirement Analysis - Knowledge on requirement gathering and analysis methodologies like UML, Process Mapping techniques like Flowcharting, IDEF etc respectively would be desirable. The person should be exposed to atleast one of the industry standards.
Process Mapping Skills – The BA should have the ability to understand and model as-is as well as future state processes. Various methodologies are followed across the industry and being skilled in atleast one of them would help in making disciplined process maps.
Domain knowledge – A basic understanding of the project domain is required for an effective requirement analysis
Communication and Documentation Skills - Clarity and crispness in communication is a virtue that the BA should posses, for verbal as well as written communication. Project scope is a controversial topic always and the BR documents act as a fallback for any dissention that arises during the project life cycle.
Analytical Skills & Foresight - BAs should have the ability to carry out an in-depth requirement analysis. Foresight should be employed while evaluating and prioritizing requirements and end users usually are not equipped to do this by themselves. Business Requirements also change with the pace that business changes today, and scope / change management becomes a challenge for almost every project. In order to manage and incorporate changes effectively, impact analysis skills would prove to be very helpful. Also, while interviewing end users, the BA should be able to strike a balance between retaining the focus on the project scope and ensuring that all aspects of the project scope are covered.
IT Skills – It is desirable that BAs possess at least a high level knowledge about software applications and architectures, RDBMS concepts, Software Development Life Cycle and Project Management methodologies.

Qualification background:

As far as qualifications are concerned, there is no one particular course/degree available for Business Analysts. The role itself has evolved over a period of time and still does not have a consolidated body of knowledge as other streams like Project Management do. (Project Management Institute for instance). Although, recently there have been quite a few initiatives like the IIBA which aim to bring consistency, knowledge sharing and consolidation in the BA community. A lot of books and online articles are also available, but experience in this walk of life teaches like no other.

Business Analysts can stem from various units of an organization – finance, IT, business user groups. A person with an inclination towards a Techno-Functional Role and with at least a high level understanding of IT capabilities can be a potential candidate for the Business Analyst role. Domain knowledge may not be a pre-requisite for beginners but is considered as a nice-to-have factor.

Career Path:

Competency development in this field is not burdened with the threat of stagnation, atleast if one has chosen the right organization. Although, a point worth mentioning here is that there are quite a few organizations where BAs are looked upon as ‘creatures’ with obscure profiles. This is because a BA’s role does not always fit into standard functions like ‘Finance’, ‘Marketing’, ‘Operations’ and also not purely into ‘IT’. Whether BAs should have a separate department or not, is a debate by itself. So increasing awareness about this role is something that is desirable.

As a BA matures, there are two to three streams that one can choose from. A logical extension for a BA would be Project Management or Consulting, depending on the competency set. Also, with the increasing advances in technology and technological needs, specialization is emerging to be an anchor for a BA. BAs could be specializing in industries like BFSI, manufacturing, and logistics; in horizontals like Business Intelligence, BPM, CRM etc; or in products like SAP, Siebel where BAs are employed to gather requirements, customize the application and be part of the implementation team.